Иногда при установке cервера VMware vCenter 5.1 или толстого клиента VMware vSphere Client 5.1 (пока мы еще ждем vSphere 5.5) на Windows Server 2012 мы получаем вот такое сообщение:
Internal error 28173
Это все потому, что у вас не установлен Microsoft .NET Framework 3.5, который требуется для работы компонентов VMware vCenter.
Решается проблема просто. Надо запустить Server Manager, запустить мастер "Add roles and features wizard" и установить .NET Framework 3.5:
После этого установка vCenter или vSphere Client пройдет успешно.
На прошедшей конференции VMworld 2013 компания VMware представила свое виденье концепции ЦОД будущего - Software-Defined Datacenter, то есть датацентр, определяемый и направляемый программно, в котором слой оборудования полностью отделен от слоя программного обеспечения, а последний и реализует все необходимые сервисы пользователей и функции управления. То есть, оборудование - это просто подложка, элементы которой можно будет заменять, а все необходимые функции управления будут находиться на стороне программного обеспечения.
Выглядит это так:
В рамках этой концепции было объявлено о работе VMware в четырех направлениях:
Расширение применения технологии виртуализации на все приложения (например, кластеры Hadoop).
Трансформация хранилищ в абстрагированные и агрегированные дисковые ресурсы серверов (Virtual SAN) на базе разработок компании Virsto (с русскими корнями, кстати).
Создание программно-определяемых сетей в датацентре на базе продукта VMware NSX, полученного после покупке компании Nicira.
Сегодня мы поговорим о третьем пункте - решении для построения виртуальной инфраструктуры сетей - VMware NSX, которое было анонсировано на VMworld как один из ключевых компонентов стратегии VMware в рамках концепции Software-defined networking (SDN).
VMware NSX - это решение полученное на основе двух продуктов: купленного Nicira NVP и собственного VMware vCloud Networking and Security (vCNS). Последний предназначен для комплексной защиты виртуального датацентра и построен на базе семейства продуктов VMware vShield. Решение VMware NSX предназначено для крупных компаний, которые планируют повысить степень гибкости сетевой среды датацентра, который связан с другими ЦОД компании, и где требуется переносить виртуальные машины между ними или поддерживать распределенную архитектуру кластеров.
Чтобы понять концепцию NSX можно провести аналогию с серверной виртуализацией, отмапив инфраструктуру VMware vSphere на инфраструктуру "гипервизора" NSX:
Такая архитектура, конечно же, требует интеграции с агентами в физическом оборудовании, которые уже есть в сетевых устройствах Arista, Brocade, Cumulus, Dell, HP и Juniper.
Сама же платформа VMware NSX включает в себя следующие компоненты:
Controller Cluster - это система, состоящая из виртуальных или физических машин (как минимум 3), предназначенная для развертывания виртуальных сетей во всем датацентре. Эти машины работают в кластере высокой доступности и готовы принимать управляющие команды от различных средств через API, например, VMware vCloud или OpenStack. Кластер осуществляет управление объектами vSwitches и Gateways, которые реализуют функции виртуальных сетей. Он определяет топологию сети, анализирует поток трафика и принимает решения о конфигурации сетевых компонентов.
Hypervisor vSwitches (NSX Virtual Switches) - это виртуальные коммутаторы уровня ядра ESXi с программируемым стеком L2-L4 и конфигурационной базой. Они отвечают за работу с трафиком виртуальных машин, обеспечение туннелей VXLAN и получают команды от Controller Cluster.
Gateways - это компоненты, предназначенные для сопряжения виртуальных и физических сетей. Они предоставляют сервисы IP routing, MPLS, NAT, Firewall, VPN, Load Balancing и многое другое.
Ecosystem partners - партнеры могут интегрировать собственные виртуальные модули (Virtual Appliances) в инфраструктуру NSX на уровнях L4-L7. Подробнее об этом написано здесь.
NSX Manager - это централизованное средство управления виртуальными сетями датацентра (с веб-консолью), которое взаимодействует с Controller Cluster.
Посмотрим на высокоуровневую архитектуру решения:
Как мы видим, NSX оперирует собственными виртуальными сетями, которые инкапсулируют в себе физические сети средствами протоколов STT, VXLAN и GRE (как это делается мы уже писали вот тут). А компонент NSX Gateway выполняет функции моста для коммутации на уровне L2 и маршрутизации на уровне L3.
В качестве серверных гипервизоров в инфраструктуре NSX могут быть использованы решения VMware vSphere, KVM или Xen.
Надо отметить, что есть два варианта развертывания решения:
Окружение, состоящее только из хостов vSphere: в этом случае NSX опирается на инфраструктуру vSphere Distributed Switch (VDS) при взаимодействии с компонентами решения. А компонент NSX Gateway опирается на решение NSX Edge, которое было выделено из подпродукта vCNS Edge (бывший vShield Edge).
Гибридное окружение с несколькими гипервизорами: тут NSX уже использует Open vSwitch для KVM и Xen, а также собственный виртуальный коммутатор NSX vSwitch, работающий на уровне ядра ESXi. С точки зрения шлюза тут уже NSX может использовать различные физические модули.
Вот так выглядит детальная архитектура решения VMware NSX с учетом развертывания в среде только с VMware vSphere (обратите внимание, что NSX может работать только с одним сервером vCenter - это ограничение архитектуры):
Тут видно, что на уровне гипервизора работают 4 компонента, так или иначе используемых NSX:
Distributed Firewall - распределенный сетевой экран, который мы упоминали вот тут.
А вот так выглядит решение NSX в гибридной среде с несколькими гипервизорами:
С точки зрения логических функций NSX выполняет следующее:
Logical Switching - NSX использует комбинацию Stateless Transport Tunneling (STT), Generic Routing Encapsulation (GRE) и VXLAN для гибридных окружений или только VXLAN для окружений vSphere, чтобы предоставлять коммутацию уровня L2 вне зависимости от нижележащей топологии сети. Теперь все происходит на уровне эмулируемой структуры виртуальных сетей, не затрагивающей IP-адреса и не привязанной к физическому расположению, что значит, что виртуальную машину можно перемещать между датацентрами без изменения конфигурации сетей.
Поддержка аппаратных туннелей - VXLAN Tunnel Endpoints (VTEPs), которые позволяют поддерживать технологию виртуальных сетей на аппаратном уровне и не создавать задержек в сети.
Logical Routing - теперь L3-маршрутизация возможна на логическом уровне, вне зависимости от нижележащего оборудования и за счет наличия distributed routing (DR) module в VMware ESXi с поддержкой протоколов динамической маршрутизации BGP и OSPF.
Logical Firewalling - эти возможности пришли из продукта vCNS App (vShield App), они позволяют обеспечить комплексную защиту датацентра средствами модулей распределенного сетевого экрана (distributed firewall, DFW).
Logical Load Balancing and VPN - эти функции были также взяты из vCNS и поддерживаются только для окружений vSphere. В этом случае компонент NSX Edge осуществляет балансировку соединений на уровне L7 с поддержкой различных алгоритмов, а также позволяет организовать надежный VPN-туннель к инфраструктуре на базе IPsec и SSL.
Более подробно о решении VMware NSX можно узнать на этой странице.
Как вы уже знаете, не так давно была выпущена обновленная версия платформы виртуализации VMware vSphere 5.5, которая получила немало новых возможностей. Вместе с тем была также выпущена бесплатная версия VMware vSphere Hypervisor 5.5 (free ESXi 5.5).
Самым главным улучшением VMware ESXi 5.5, бесспорно, стало отсутствие ограничений на физическую память хост-сервера. Если раньше мы могли использовать бесплатный ESXi только на серверах, где установлено до 32 ГБ RAM:
то теперь VMware ESXi 5.5 не имеет абсолютно никаких ограничений сверху по памяти физического сервера.
Это хорошая новость, но есть и немного плохая. Если ограничения сверху теперь отсутствуют, то ограничения снизу всегда будут - это системные требования. В версии ESXi 5.0 для запуска хоста требовалось минимум 2 ГБ оперативной памяти (если вы ставили его в кластер, то уже требовалось 3 ГБ, так как с двумя гигами хост вылетал в PSOD). В версии же ESXi 5.5 теперь официально требуют 4 ГБ RAM. Это значение важно, конечно же, не для физических хостов ESXi 5.5, а для виртуальных - которые используются для тестирования возможностей инфраструктуры виртуализации.
Отметим, что ограничение на 8 vCPU на одну виртуальную машину в бесплатном ESXi 5.5 осталось.
Ну а с точки зрения самого бесплатного гипервизора VMware ESXi 5.5 появились следующие новые возможности:
Обновленная версия виртуального аппаратного обеспечения - Virtual Machine Hardware Version 10.
Поддержка новых архитектур CPU.
Совместимость ВМ в VMware ESXi 5.5 - теперь обеспечивается обратная совместимость ВМ с поддержкой различных возможностей, таких как LSI SAS для Oracle Solaris 11 OS и advanced host controller interface (AHCI).
Максимальное число vCPU на хост - 4096 (было 2048).
NUMA-узлов на хост - 16 (было 8).
Логических CPU на хост - 320 (было 160).
Поддержка дисков VMDK до 62 ТБ.
Поддержка адаптеров 16 GB Fibre Channel.
Поддержка сетевых адаптеров до 40 GBps.
До 64 ТБ хранилищ на один хост ESXi.
Один SATA-контроллер поддерживает виртуальный диск и CD-ROM на одном контроллере.
Поддержка до 30 устройств на контроллер, всего 4 контроллера - итого 120 устройств.
Ограничение на non-writable API все еще осталось, поэтому непонятно, как работают такие решения, как бесплатный Unitrends Enterprise Backup (UEB) - заявлено, что он может бэкапить виртуальные машины бесплатного ESXi.
Продолжаем знакомить вас с анонсами VMworld 2013, среди которых было немалоинтересного. Как вы помните, у компании VMware в основном продуктовом портфеле есть решение VMware Site Recovery Manager, предназначенное для построения катастрофоустойчивой архитектуры на базе основной и резервной площадок. О предыдущей версии VMware SRM 5.1 мы уже писали вот тут. Ну а сегодня расскажем про VMware Site Recovery Manager 5.5.
Но сначала для тех, кто хочет знать, как об этом рассказывали на VMworld:
Напомним, что в SRM можно использовать репликацию на уровне дисковых массивов (array-based), которая работает быстро, надежно (до RPO=0) и синхронно (или асинхронно), но требует вложений в инфраструктуру, а также host-based репликацию по сети передачи данных, которая работает менее эффективно (RPO - от 15 минут до 24-х часов), зато использует существующую инфраструктуру Ethernet. О некоторых улучшениях host-based репликации в VMware vSphere 5.5 мы уже упоминали в этой статье.
Итак, что нового появилось в VMware SRM 5.5:
Возможность протестировать процедуру аварийного восстановления с двух сторон, без нарушения работы производственного окружения.
Поддержка виртуальных машин с дисками более 2 ТБ.
Поддержка Windows Server 2012 для установки компонентов SRM.
Новые настройки для поддержки режима vSphere Replicaiton.
При перемещении машин в рамках одной consistency group полностью поддерживаются техники Storage DRS и Storage vMotion.
Защита виртуальных машин, хранилища которых находятся на бэкэнде Virtual SAN (vSAN). Естественно, это реализовано на базе vSphere Replication.
Поддержка техники multiple point-in-time (MPIT) - нескольких точек для восстановления целевой реплицируемой машины. Это защищает сервисы от логических повреждений данных, изменения в которых реплицируются на резервную площадку.
SRM 5.5 больше не поддерживает базу данных IBM DB2.
Надо отметить, что для управления инфраструктурой SRM по-прежнему требуется "толстый" клиент vSphere Client (напомним, что его не убрали из vSphere 5.5, хотя и обещали - похоже именно из-за сопутствующих продуктов), а про поддержку vSphere Web Client пока ничего не говорят.
Интересной новой возможностью, о которой шла речь на VMworld, стал сценарий создания резервной инфраструктуры SRM в одном из поддерживаемых публичных облаков (он может быть использован как общий Recovery-сайт для нескольких филиалов компании):
Лицензирование продукта осталось прежним - либо за защищаемые виртуальные машины (если покупаем просто SRM), либо по процессорам хостов VMware ESXi (если покупаем в составе vCloud Suite).
О доступности для загрузки VMware Site Recovery Manager 5.5 будет объявлено несколько позднее.
Ну и помните (на всякий случай) предупреждение VMware:
Using SRM and vSphere Replication to replicate and recover virtual machines on VMware Virtual SAN datastores can results in incomplete replications when the virtual machines are performing heavy I/O. ESXi Server can stop unexpectedly.
Кстати, в будущем нам обещают, что VMware SRM будет доступен в виде виртуального модуля (Virtual Appliance).
Таги: VMware, SRM, Update, vSphere, Replication, DR
Как многие из вас знают, сейчас проходит конференция VMworld 2013, проводимая компанией VMware, на которой было сделано немало интересных анонсов в продуктовой линейке ведущего вендора решений для виртуализации.
Приведем здесь список того, что было анонсировано и где можно почерпнуть дополнительной информации:
Обновилась платформа виртуализации - VMware vSphere 5.5. О новых возможностях vSphere 5.5 мы написали тут. Обратим внимание, что цены и издания продукта не изменились.
Изменилась комплектация и стоимость некоторых продуктов VMware. Об этом мы писали вот тут.
Обновился пакет VMware vCloud Suite 5.5, включающий в себя основные решения для организации частного облака на основе VMware vSphere 5.5. Мы писали об этом тут. А о новых особенностях версии 5.5 можно прочитать тут. В ближайшее время мы расскажем об этом подробнее.
Обновилось решение для автоматизации частного облака vCloud Director 5.5, подробнее об этом можно почитать тут. Скоро и здесь об этом будет.
Обновились службы единого входа Single Sign On 2.0. Подробности приведены здесь.
Был существенно улучшен механизм vSphere Replication 5.5. Некоторые детали приведены у нас тут. На английском можно почитать здесь.
Обновилось решение для создания катастрофоустойчивой инфраструктуры VMware Site Recovery Manager 5.5. Скоро мы об этом здесь также напишем. Пока почитайте о нем вот тут.
Обновилось решение
vSphere Data Protection Advanced, которое входит в состав VMware vSphere для изданий, начиная с vSphere Essentials Plus (напомним, что выпущено оно было еще в начале года). Почитать можно тут.
Была анонсирована доступность средства vCloud Planner 1.0 (он же бывший VMware Infrastructure Planner / VIP), предназначенного для финансовой оценки планируемой виртуальной инфраструктуры на базе дополнительных решений в рамках концепции Software Defined Datacenter на основе VMware vCloud Suite (то есть, что улучшится с точки зрения владения инфраструктурой, если закупить и развернуть последний). В качестве отправной точки для расчетов используется уже существующая инфраструктура на основе VMware vSphere. Подробнее об этом средстве можно узнать тут.
Было анонсировано средство, предназначенное для виртуализации сетей в рамках концепции Software-defined networking (SDN) - VMware NSX, о котором мы писали вот тут. Немного дополнительной информации находится здесь. Скоро мы также опишем его несколько подробнее.
Анонсировали обновленную версию решения для комплексного мониторинга и защиты сетей
vCloud Networking and Security 5.5 в составе vCloud Suite 5.5. Подробнее об этом тут.
Выпустили новую минорную версию решения для высокой доступности сервисов vCenter - vCenter Server Heartbeat 6.6.
Ну и (если кто не заметил) обновился сайт VMware. Теперь все так модно делать - в стиле Ленты.ру.
Скоро о многом из этого мы расскажем достаточно подробно. Заходите чаще!
Не так давно мы уже писали о планируемых новых возможностях VMware vSphere 5.5, однако большинство новых функций были описаны в общих чертах, кроме того, до последнего момента так и не было окончательно известно, что же еще нового появится в vSphere 5.5. На проходящей сейчас конференции VMworld 2013 компания VMware наконец-то объявила о выходе обновленной платформы VMware vSphere 5.5, которая стала еще более мощным средством для построения виртуальных инфраструктур.
Мы продолжаем сотрудничество с компанией Код Безопасности, которая выпускает продукт vGate R2, предназначенный для защиты виртуальных инфраструктур средствами политик, а также от несанкционированного доступа к элементам инфраструктуры, таким как виртуальные машины, хранилища и сети.
vGate R2 – это сертифицированное средство защиты информации от несанкционированного доступа и контроля выполнения ИБ-политик для виртуальной инфраструктуры на базе платформ VMware vSphere 4 и vSphere 5. vGate R2 облегчает приведение виртуальной инфраструктуры в соответствие законодательству, отраслевым стандартам и лучшим мировым практикам.
Защита информации от утечек через специфические каналы среды виртуализации.
Разделение объектов инфраструктуры на логические группы и сферы администрирования через мандатное и ролевое управление доступом.
Усиленная аутентификация, разделение ролей и делегирование полномочий.
Управление и контроль над конфигурацией системы безопасности.
Автоматическое приведение инфраструктуры в соответствие требованиям и постоянный
контроль соответствия.
Решение vGate R2 имеет все необходимые сертификаты ФСТЭК, так необходимые в государственных организациях, а также в компаниях, оперирующих с персональными данными. Сертификат ФСТЭК России по уровню СВТ 5 и НДВ 4 дает возможность использовать продукт для защиты автоматизированных систем (АС) до класса 1Г включительно и информационных систем персональных данных (ИСПДн) до класса К1 включительно.
Более подробную информацию о продукте vGate R2 можно получить на этой странице.
В ближайшее время мы расскажем о следующих интересных моментах, касающихся vGate R2:
Встроенные средства защиты в сертифицированную (теперь) платформу VMware vSphere и продукт vGate 2.5 (VMware выполняет не все требования).
Многие ИТ-специалисты, имеющие отношение к виртуализации, конечно же, знают о сертификации VMware Certified Professional (VCP), которая дается по прохождению одного из авторизованных курсов по продуктам VMware и последующей сдаче экзамена.
На одном из блогов VMware появилась интересная инфографика:
Честно говоря, я был несколько удивлен. Всего 753 VCP в России? Я думал счет идет уже на тысячи. А нет - выходит, что у нас их меньше, чем в ЮАР или Польше. Надеюсь, их хотя бы больше, чем в Мозамбике.
Дорого учиться, ломно сдавать экзамен, просто пофиг на сертификации или что-то еще? Может у кого есть полная версия данных для этой инфографики или, например, распределение сертифицированных специалистов по другим вендорам?
Был тут случай недавно - пишет мне товарищ, дескать, что это мы пост разместили с инфой, которая под NDA. А откуда мы должны знать, что находится под NDA, а что не под NDA? И вообще с какой стати все эти заморочки с NDA? Я вообще на тему продуктов чьих-то NDA никогда не подписывал и подписывать не собираюсь. А если появляется утечка с новыми возможностями продукта или компании - это никакой нахрен не слив инфы под NDA, а самая обычная и уже набившая оскомину реклама - радуйтесь.
Или вот приходит нам рассылка про новую версию vCloud Director, а внизу написано:
***** Confidential Information ***** Do not forward information about this program or release to anyone outside of those directly involved with beta testing. This information is highly confidential.
Information contained in this email, including version numbers, is not a commitment by VMware to provide or enhance any of the features below in any generally available product.
Или вот NVIDIA пишет:
Обращаю ваше внимание, что информация брифинга находитсяпод NDAдо 17:00 по Москве вторника, 23-го июля.
И чо? А если я им в письме напишу, что им нельзя мыться 3 месяца - они будут этот наказ соблюдать?
Так что, уважаемые вендоры, надеюсь, вам понятна позиция VM Guru с вашими NDA. Если мы их не подписывали - не пишите нам ничего на эту тему, так как эти письма отправляются прямиком в трэш по ключевому слову "NDA".
Вон у Apple тоже, конечно, утечки бывают, но в целом-то - хрен узнаешь, когда этот новый айфон выйдет. Поэтому в этом посте мы с удовольствием расскажем о новых возможностях VMware vSphere 5.5 на основе информации, взятой из сети интернет (также об этом есть на блоге Андрея и Виктора - http://vmind.ru/2013/08/15/chego-zhdat-ot-vmware-vsphere-5-5/). Естественно, не все из этих фичей могут оказаться в релизной версии, и это, само собой, не полный их список.
New OS Support
Наряду с поддержкой Windows 8.1 (ожидается в VMware View 5.5) будут поддерживаться последние релизы гостевых ОС Linux: Ubuntu, Fedora, CentOS, OpenSUSE и другие дистрибутивы.
VMware Hardware Version 10
Теперь появится новое поколение виртуального аппаратного обеспечения версии 10. Это добавит новых возможностей виртуальным машинам с точки зрения динамических сервисов виртуализации. Для редакции vSphere Enterprise Plus будет поддерживаться до 128 vCPU.
Улучшенный интерфейс, большое количество фильтров и вкладка "recent objects", позволяющая получить быстрый доступ к объектам.
Улучшения по времени отклика интерфейса и возможность управлять большим числом объектов.
vSphere Replication - теперь доступны следующие возможности по репликации виртуальных машин:
Возможность репликации виртуальных машин между кластерами для машин не с общими хранилищами (non-shared storage).
Поддержка нескольких точек для восстановления целевой реплицируемой машины. Это защищает сервисы от логических повреждений данных, изменения в которых реплицируются на резервную площадку.
Storage DRS Interoperability - возможность реплицируемых машин балансироваться по хранилищам средствами технологии Storage vMotion без прерывания репликации.
Simplified Management - улучшенная интеграция с vSphere Web Client, что позволяет мониторить процесс репликации в различных представлениях vCenter.
Поддержка технологии VSAN (см. ниже) - теперь машины на таких хранилищах поддерживаются средствами репликации.
vCenter Orchestrator - теперь это средство автоматизации существенно оптимизировано в плане масштабируемости и высокой доступности. Разработчики теперь могут использовать упрощенные функции диагностики в vCenter Orchestrator client.
Virtual SAN
О возможностях VMware Distributed Storage и vSAN мы уже писали вот в этой статье. Virtual SAN - это полностью программное решение, встроенное в серверы VMware ESXi, позволяющее агрегировать хранилища хост-серверов (SSD и HDD) в единый пул ресурсов хранения для всех хостов, что позволяет организовать ярусность хранения с необходимыми политиками для хранилищ.
Поддержка томов vVOL
Также мы писали о поддержке виртуальных томов vVOL - низкоуровневых хранилищ для каждой из виртуальных машин, с которыми будут позволены операции на уровне массива, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. Проще говоря, VMDK-диск машины можно будет хранить как отдельную сущность уровня хранилищ в виде vVOL, и с ней можно будет работать отдельно, без влияния на другие ВМ этого массива.
VMware Virtual Flash (vFlash)
О возможностях VMware Virtual Flash (vFlash) мы уже писали вот в этой статье. vFlash - это средство, позволяющее объединить SSD-ресурсы хост-серверов VMware ESXi в единый пул, используемый для задач кэширования, чтобы повысить быстродействие виртуальных машин. vFlash - это фреймворк, позволяющий сторонним вендорам SSD-накопителей и кэш-устройств использовать собственные алгоритмы для создания модулей обработки кэшей виртуальных машин (плагины vFlash Cache Modules). Будет реализован и собственный базовый алгоритм VMware для работы с кэшем.
Virtual Machine File System (VMFS)
Теперь VMware vSphere 5.5 поддерживает vmdk-диски объемом более 2 TБ. Теперь объем виртуального диска машины может быть размером до 64 ТБ. Несколько больших файлов теперь могут храниться в одном vmdk. Это поддерживается только для VMFS 5.
vCloud Director
Теперь продукт доступен как виртуальный модуль (Virtual Appliance) - можно использовать как встроенную так и внешнюю БД. Этот модуль по-прежнему не будет рекомендован для продакшен-среды. Рекомендуют использовать его для апробации решения.
Был существенно улучшен Content Catalog:
Улучшена производительность и стабильность синхронизации
Расширяемый протокол синхронизации
Возможность самостоятельной загрузки элементов каталога (OVF)
Кроме того, для интерфейса управления теперь поддерживается больше браузеров и ОС (в том числе поддержка Mac OS).
vCloud Networking & Security
В составе vSphere 5.5 этот продукт будет иметь следующие улучшения:
Улучшенная поддержка Link Aggregation Control Protocol (LACP) - теперь поддерживается 22 алгоритма балансировки и до 32 физических соединений в агрегированном канале.
Улучшения производительности и надежности агрегированного канала.
Кроме того, вместо vCloud Networking and Security с октября выходит новый продукт VMware NSX.
Security Features
Теперь появится распределенный сетевой экран (Distributed Firewall), являющийся одним из ключевых компонентов концепции Software Defined Datacenter. Он работает на уровне гипервизора каждого из хостов VMware ESXi, а на уровне централизованной консоли доступен мониторинг проходящих пакетов от абсолютно каждой виртуальной машины.
Политики этого сетевого экрана определяются на уровне VXLAN, поэтому нет нужды оперировать с ним на уровне IP-адресов. Ну и так как поддержка этого распределенного фаервола реализована на уровне гипервизора - то политики перемещаются вместе с виртуальной машиной, если она меняет хост средствами vMotion.
Теперь vCenter SRM будет поддерживать технологию vSAN вместе с vSphere Replication, работать с технологиями Storage DRS и Storage vMotion. Кроме того, добавлена поддержка нескольких точек восстановления реплик (Multi-Point-In-Time snapshots) при исполнении плана аварийного восстановления.
VMware vCenter Multi-Hypervisor Manager (MHM) 1.1
Об этом продукте мы уже писали вот тут. Теперь он будет поддерживать гипервизор Microsoft Hyper-V 3.0 в Windows Server 2012 R2 (а также более ранние его версии). Также появилась возможность холодной миграции ВМ с хостов Hyper-V на VMware vSphere.
Single Sign-On 2.0 (SSO)
В новой версии единого средства аутентификации продуктов VMware теперь появится улучшенная и новая поддержка следующих компонентов:
vSphere
vCenter Orchestrator
vSphere Replication
vSphere AppHA (новый продукт, который будет анонсирован на VMworld)
vCloud Director
vCloud Networking and Security (vCNS)
Технология VMware vDGA для VMware Horizon View 5.5
О технологии NVIDIA VGX мы уже писали вот тут, тут и тут. Согласно этой презентации, уже скоро мы увидим возможности шаринга и выделение GPU отдельным виртуальным машинам:
Ну что знал - рассказал. В целом, ничего революционного. Поддержку Fault Tolerance для 4-х vCPU обещают в VMware vSphere 6.0.
Компания Veeam Software на днях выпустила новую версию самого лучшего в мире средства для резервного копирования виртуальных машин - Veeam Backup and Replication 7. В седьмой версии появилось не просто много новых возможностей, а очень много - всего продукт насчитывает более 50 нововведений и улучшений. Мы уже писали о новых возможностях Veeam B&R 7, а в этом посте сведем все воедино и приведем сравнение изданий.
Вот и стали появляться первые сравнения платформ виртуализации VMware vSphere 5.1 и еще невышедшего Microsoft Hyper 2012 R2 (в составе Windows Server 2012 R2). О сильных и слабых сторонах продуктов мы уже давно не спорим, так как дело это пустое, а вот таблички из статьи, содержащие немало фактического материала, спорщикам пригодятся.
Итак, что мы имеем в плане максимальных параметров, вычислительных ресурсов и масштабирования:
System
Resource
Microsoft Hyper-V 2012
VMware vSphere 5.1
Free Hypervisor
Essential Plus
Enterprise Plus
Host
Logical Processors
320
160
160
160
Physical Memory
4 TB
32 GB
2 TB
2 TB
Virtual CPUs per Host
2048
2048
2048
2048
Nested Hypervisor
No
Yes
Yes
Yes
VM
Virtual CPUs per VM
64
8
8
64
Memory per VM
1 TB
32 GB
1 TB
1 TB (max 64GB with FT)
Maximum Virtual Disk
64 TB
2 TB
2 TB
2 TB
Hot-Add
Only disks
Disks/vNIC/USB
Disks/vNIC/USB
All
Active VMs per Host
1024
512
512
512
Cluster
Maximum Nodes
64
N/A
32
32
Maximum VMs
8000
N/A
4000
4000
Сравнение vSphere 5.1 и Hyper-V 2012 R2 в плане хранилищ (Storage):
Capability
Microsoft Hyper-V 2012
VMware vSphere 5.1
Free Hypervisor
Essential Plus
Enterprise Plus
Thin disks
Yes (dynamic disks)
Yes
Yes
Yes
Differential disks
Yes
No (only with API)
No (only with API)
No (only with API)
SAN
iSCSI/FC
iSCSI/FC
iSCSI/FC
iSCSI/FC
NAS
SMB 3.0
NFS 3 over TCP
NFS 3 over TCP
NFS 3 over TCP
Virtual Fiber Channel
Yes
Yes
Yes
Yes
3rd Party Multipathing (MPIO)
Yes
No
No
Yes
Native 4-KB Disk Support
Yes
No
No
No
Maximum Virtual Disk Size
64TB VHDX
2TB VMDK
2TB VMDK
2TB VMDK
Maximum Pass Through Disk Size
265TB+
64TB
64TB
64TB
Storage Offload
Yes (ODX)
No
No
Yes (VAAI)
Storage Virtualization
No (only 3rd part)
No (only 3rd part)
VSA
VSA (limited to 3 nodes)
Storage Encryption
Yes
No
No
No
Caching
Yes (CSV read-only cache)
Swap to host cache
Swap to host cache
Swap to host cache
В плане сетевого взаимодействия различия следующие:
Capability
Microsoft Hyper-V 2012
VMware vSphere 5.1
Free Hypervisor
Essential Plus
Enterprise Plus
NIC Teaming
Yes
Yes
Yes
Yes
Extensible Switch
Yes
No
No
Replaceable
PVLAN Support
Yes
No
No
Yes (only with DVS)
ARP/ND Spoofing Protection
Yes
No
No
vCNS/Partner
DHCP Snooping Protection
Yes
No
No
vCNS/Partner
Virtual Port ACLs
Yes
No
No
vCNS/Partner
Trunk Mode to Virtual Machines
Yes
No
No
No
Port Monitoring
Yes
Per Port Group
Per Port Group
Yes
Port Mirroring
Yes
Per Port Group
Per Port Group
Yes
Dynamic Virtual Machine Queue
Yes
NetQueue
NetQueue
NetQueue
IPsec Task Offload
Yes
No
No
No
SR-IOV
Yes
Yes (No Live Migration support)
Yes (No Live Migration support)
Yes (No Live Migration support)
Network Virtualization
Yes
No
No
VXLAN
Quality of Service
Yes
No
No
Yes
Data Center Bridging (DCB)
Yes
Yes
Yes
Yes
О том, что лучше - VMware vSphere или Microsoft Hyper-V, можно рассуждать бесконечно, но однозначно можно сказать только одно - Hyper-V год от года становится значительно функциональнее, а вот VMware основные усилия по улучшению продукта направляет только на издание Enterprise Plus, купить которое не каждой компании по средствам.
Таги: VMware, vSphere, Microsoft, Hyper-V, Сравнение, Server
Как вы знаете, в августе нас ждет главное событие года в сфере виртуализации - конференция VMware VMworld 2013, где будет сделано пара интересных анонсов и будут выпущены новые продукты компании VMware. Уже сейчас стало известно несколько важных моментов, касающихся повышения цен и комплектации продуктов.
Итак, что будет происходить в сентябре этого года:
С 19 сентября 2013 произойдет повышение цен на следующие продукты:
- vCenter Operations 5.6 Management Suite Advanced - vCenter Operations 5.6 Management Suite Enterprise
С 19 сентября 2013 прекращаются продажи лицензий vCloud Director - теперь он будет продаваться только в составе комплекта vCloud Suite
С 30 сентября 2013 прекращаются продажи лицензий vCloud Networking and Security - теперь он будет продаваться только в составе комплекта vCloud Suite
С 19 сентября 2013 изменятся партномера, а также повысятся цены на лицензии, апгрейды и техподдержку для пакета VMwarevSphere 5 EssentialsPlusKitfor 3hosts.
Будет два варианта комплектации EssentialsPlusKit:
- VMware vSphere 5 Essentials Plus Kit for 3 hosts- стандартный набор из лицензий на три 2-процессорных хоста ESXi, но теперь без vSphereStorageAppliance(VSA) в своем составе. - VMware vSphere 5 Essentials Plus Kit with VSA - это vSphere 5 Essentials Plus Kit с включенным в состав компонентом vSphere Storage Appliance.
И да - для них станет доступна скидка по программе VPP.
С 19 сентября 2013 изменятся партномера у лицензий, апгрейдов и техподдержки на продукты семействаVMwarevSpherewithOperationsManagement. Цены останутся прежними.
Это коснется следующих продуктов:
- VMware vSphere with Operations Management Standard for 1 processor
-
VMware vSphere with Operations Management Enterprise for 1 processor
-
VMware vSphere with Operations Management Enterprise Plus for 1 processor
Большинству администраторов VMware vSphere известно, что у виртуальной машины могут быть виртуальные сетевые адаптеры различных типов, которые выбираются как в зависимости от гостевой ОС, так и от настроек пользователя, которые можно прописать в vmx-файле конфигурации ВМ.
На эту тему компания VMware выпустила вот такое видео:
Опишем типы сетевых адаптеров (vNIC) для виртуальной машины (ранее мы писали о них тут):
Vlance - этот адаптер эмулирует реально существующий старый адаптер AMD 79C970 PCnet32- LANCE NIC, он работает на скорости 10 Mbps, и для него есть драйверы в большинстве 32-битных ОС, за исключением Windows Vista и более поздних версий. Виртуальная машина с таким адаптером может сразу использовать сеть.
VMXNET - такой адаптер уже не имеет физического воплощения, то есть он полностью виртуальный. Он оптимизирован с точки зрения производительности ВМ. Поскольку он виртуальный - ОС не может его использовать, пока не установлены драйверы, идущие в комплекте с VMware Tools.
Flexible - это по-сути не адаптер, а способ его представления. Он ведет себя как Vlance при загрузке ВМ, но потом превращается (или нет - в зависимости от VMware Tools) в VMXNET.
E1000 - это эмулируемая сетевая карта Intel 82545EM Gigabit Ethernet NIC. Драйвер для этого адаптера есть не во всех гостевых операционных системах. Обычно Linux с версиями ядра 2.4.19 или более поздними, Windows XP Professional x64 Edition и позднее, а также Windows Server 2003 (32-bit) и позднее включают в себя драйвер для этого устройства. Производительность его достаточно неплоха. Драйвер адаптера E1000 не поддерживает большие кадры jumbo frames до версии VMware ESXi/ESX 4.1.
E1000e - этот адаптер эмулирует более продвинутую модель Intel Gigabit NIC (number 82574) в виртуальном аппаратном обеспечении (virtual hardware) виртуальной машины. Адаптер e1000e доступен только для virtual hardware версии 8 (и старше), начиная с VMware vSphere 5. Это дефолтный адаптер для Windows 8 и более новых гостевых ОС. Для гостевых ОС Linux e1000e не доступен для выбора из интерфейса (e1000, flexible, vmxnet, enhanced vmxnet и vmxnet3 - доступны для Linux).
VMXNET 2 (Enhanced) - адаптер VMXNET 2 основан на устройстве VMXNET, но предоставляет несколько функций с улучшенной производительностью, таких как jumbo frames и hardware offloads (например, TCP Segmentation Offloading, TSO). Этот адаптер доступен только для хостов VMware ESX/ESXi 3.5 или выше. Устройство VMXNET 2 поддерживается только для следующих гостевых операционных систем:
32- и 64-битные версии Microsoft Windows 2003 (Enterprise и Datacenter Edition). Можно использовать адаптер VMXNET 2 и на Microsoft Windows 2003, однако нужно прочитать статью в KB 1007195 (http://kb.vmware.com/kb/1007195).
32-битная версия Microsoft Windows XP Professional
32- и 64-битные версии Red Hat Enterprise Linux 5.0
32- и 64-битные версии SUSE Linux Enterprise Server 10
В ESX 3.5 Update 4 или более поздних версиях платформы следующие гостевые ОС также поддерживаются для этого адаптера:
Microsoft Windows Server 2003, Standard Edition (32-bit)
Microsoft Windows Server 2003, Standard Edition (64-bit)
Microsoft Windows Server 2003, Web Edition
Microsoft Windows Small Business Server 2003
Jumbo frames также не поддерживаются для гостевых ОС Solaris с адаптером VMXNET 2.
VMXNET 3 - это следующее поколение виртуальных сетевых карт, которое теперь паравиртуализовано. То есть часть того, что раньше полностью эмулиировалось, теперь передается напрямую в физическое устройство. Этот адаптер не является надстройкой над VMXNET или VMXNET 2, но включает в себя все доступные для них возможности. Например, к ним относятся: поддержка механизмов нескольких очередей (multiqueue - также известны как Receive Side Scaling в Windows), IPv6 offloads, а также прерывания MSI/MSI-X (подробнее - тут).
VMXNET 3 поддерживается только для виртуальных машин с виртуальным аппаратным обеспечением уровня 7 или более поздним, при этом только для следующих гостевых систем:
32- и 64-битные версии Microsoft Windows XP и более поздние (включая Windows 7, 2003, 2003 R2, 2008, 2008 R2 и Server 2012)
32- и 64-битные версии Red Hat Enterprise Linux 5.0 и более поздние
32- и 64-битные версии SUSE Linux Enterprise Server 10 и более поздние
32- и 64-битные версии Asianux 3 и более поздние
32- и 64-битные версии Debian 4/Ubuntu и более поздние
32- и 64-битные версии Sun Solaris 10 U4 и более поздние
Заметки:
В ESXi/ESX 4.1 и более ранних версиях jumbo frames не поддерживаются для гостевых ОС Solaris для адаптеров VMXNET 2 и VMXNET 3. Эта возможность поддерживается, начиная с ESXi 5.0 только для адаптеров VMXNET 3. Более подробно можно почитать в статье Enabling Jumbo Frames on the Solaris guest operating system (2012445).
Технология Fault Tolerance не поддерживается для ВМ с адаптером VMXNET 3 в vSphere 4.0, но поддерживается в vSphere 4.1 и более поздних версиях.
Windows Server 2012 поддерживается для адаптеров e1000, e1000e и VMXNET 3 на платформе ESXi 5.0 Update 1 и более поздни
Для того, чтобы использовать тот или иной тип виртуального сетевого адаптера для виртуальной машины, необходимо выставить его при добавлении к виртуальной машине при создании или редактировании свойств.
Также vNIC можно добавить с помощью добавления строчек в конфигурационный vmx-файл виртуальной машины:
Для адаптера типа Flexible ничего добавлять не требуется.
Ethernet[X].virtualDev = "e1000" - для добавления сетевого адаптера E1000.
Ethernet[X].virtualDev = "vmxnet" - для добавления адаптера VMXNET 2 (Enhanced).
Ethernet[X].virtualDev = "vmxnet3" - для добавления адаптера VMXNET3.
Вместо [X] необходимо подставить номер виртуального сетевого адаптера, начиная с 0.
Компания «Сертифицированные информационные системы», получила сертификат Федеральной службы по техническому и экспортному контролю (ФСТЭК России) на программное обеспечение для виртуализации центра обработки данных — VMware vSphere 5.1 и программное обеспечение для виртуализации рабочих мест – VMware View 5.1. Российским заказчикам стали доступны преимущества использования сертифицированных версий решений для организации и управления виртуальной инфраструктурой.
Сертификат соответствия ФСТЭК России № 2900 от 13 июня 2013 года удостоверяет, что программный комплекс VMware vSphere 5.1, в редакции «Standard», «Enterprise», «Enterprise Plus», «VMware View 5.1» в редакциях «Premier», «Enterprise», разработанный компанией VMware и производимый ООО «Сертифицированные информационные системы», является программным средством общего назначения со встроенными средствами защиты от несанкционированного доступа к информации, не содержащей сведений, составляющих государственную тайну.
Смущает тут одно - "Программный комплекс VMware vSphere 5.1...производимый ООО «Сертифицированные информационные системы»". Это что еще такое? Я почему-то думал, что VMware vSphere производит сама компания VMware :) Ну да ладно.
Полученный решениями vSphere и View сертификат ФСТЭК позволяет использовать VMware vSphere 5.1 и VMware View 5.1 в информационных системах для обеспечения 4-го уровня защищенности ПДн и 3-го уровня при использовании дополнительных средств в ИСПДн-С, ИСПДн-Б, ИСПДн-О, ИСПДн-И с актуальными угрозами 3-го типа. При использовании сертифицированных СЗИ от партнеров VMware ПО виртуализации можно использовать в АС с более высокими требованиями к защите информации.
Относительно получения сертификата просьба обращаться к VMware:
Мурашов Максим
консультант по решениям
mmurashov@vmware.com
+7 495 212 2950
P.S. Те из вас, кто сертификат уже получил - киньте, пожалуйста, линк в каменты.
Еще в 2010 году мы писали о продукте VMware vCenter Configuration Manager 5.3 (не путать с vCenter Operations Manager), который позволяет управлять конфигурациями виртуальной среды на базе политик (проверка соответствия), а также обновлять различные сервисы в ИТ-инфраструктуре крупного предприятия. Этот продукт может быть интегрирован с пакетом vCenter Operations Manager Suite, а по своей сути напоминает майкрософтовский System Center Configuration Manager (SCCM).
Примеры проверки соответствия политикам в инфраструктуре предприятия с помощью VMware vCCM:
На днях вышла версия VMware vCenter Configuration Manager 5.7, которая, оказывается, продвинулась с 2010 года всего на 0.4 версии, что говорит о том, что VMware не уделяет большого внимания этому продукту.
Новые возможности vCenter Configuration Manager 5.7:
1. Enhanced OS Patching - улучшенные механизмы наката обновлений на гостевые ОС.
Что нового в этой категории:
Dynamic Templates - теперь в шаблон обследования можно автоматически включать новые бюллетени обновлений, то есть не приходится их теперь добавлять в шаблоны руками.
Automatic Patch Deployment - теперь можно задавать параметры автоматического накатывания обновлений, включая триггер по наступлению события, а также обновление по времени.
Patching Exceptions - для патчей можно задавать, исключения, позволяющие, например, не накатывать определенную версию патча для некоторых систем, в которых существуют проблемы совместимости.
Improved Linux/Unix Patching - улучшения, связанные с обновлением *nix-систем.
2. Simplified Install and Setup - упрощенная установка.
Теперь процесс установки и настройки vCenter Configuration Manager стал простым и быстрым. На эту тему даже сняли видео:
По сути, поставить продукт теперь можно методом Next-next-next.
3. Enhanced vSphere Support - улучшенная поддержка платформы виртуализации VMware vSphere.
Тут появились 3 основных улучшения:
Performance Improvements - теперь до 87% сократилось время сбора данных с хостов VMware vSphere.
Granular Control Over Data Collections - теперь очень детально можно указывать, какие именно данные нужно собирать с инфраструкутры VMware vSphere.
New Report – появился отчет Virtual Environments Virtual Devices Details.
4. Platform Enhancements - улучшения самого продукта.
Improved Self-Diagnostics - теперь в разделе "Администрирование" есть возможность в отдельном интерфейсе просмотреть состояние самой системы vCCM.
New Look and Feel - теперь интерфейс больше походит на VMware vSphere и vCenter Operations Manager.
Поддержка SQL Server 2012.
Напоследок небольшое видео об интеграции vCCM с продуктом vCenter Operations Manager:
Скачать продукт VMware vCenter Configuration Manager 5.7 просто так нельзя. Для запроса пробной версии нужно связываться напрямую с VMware.
Иногда, вследствие ошибки или отсутствия поддержки каких-либо функций, появляется необходимость обновить драйвер HBA-адаптера на сервере VMware ESXi - ведь ждать очередного обновления vSphere с обновленными драйверами можно очень долго.
Поэтому можно обновиться самим - это просто. Смотрим на свои адаптеры HBA, для чего выполняем команду:
# esxcfg-scsidevs -a
Здесь мы видим в каких слотах сервера размещены адаптеры (и производителя адаптера), но не видим версий их Firmware. Поэтому смотрим в девайсы, например для адаптера Qlogic (как смотреть остальные - тут):
# more /proc/scsi/qla2xxx/0
Здесь мы видим версию Firmware - 5.03.15 и метку версии драйвера.
Далее нужно посмотреть в KB 2030818 (Supported Driver Firmware versions for I/O devices) для того, чтобы определить поддерживаемые для ESXi драйверы адаптеров и рекомендации по текущей версии.
Например, для серверов HP идем в http://vibsdepot.hp.com/hpq/recipes/, где находим документ "HP-VMware-Recipe.pdf", в котором есть ссылки на необходимые драйверы:
Оказывается, одна британская компания выпускает интересное устройство под названием Raspberry Pi, представляющее собой маленький и немощный компьютер на базе процессора ARM11, предназначенный для выполнения небольших задач. Например, с его помощью можно детям учиться программированию или играть в какие-нибудь мини-игрушки.
Позиционируется данный девайс как "credit-card sized computer" и выглядит он вот так:
Эта штучка имеет на борту 256 или 512 МБ оперативной памяти, обычный и графический процессоры (CPU и GPU), а также необходимые интерфейсы для подключения устройств ввода-вывода (среди них HDMI и 1 или 2 USB-порта) и порт для Ethernet:
Стоит эта штучка в базовой комплектации $25 (Model A - 1 USB-порт и 256 МБ RAM) и $35 за модель постарше (Model B - 2 USB-порта и 512 МБ RAM) - без учета источника питания и preloaded SD-карты. В общем, интересный гаджет.
Недавно компания Xtravirt (мы много о ней в свое время писали) выпустила приложение Advantage vPi, представляющее собой образ с набором утилит для управления виртуальной инфраструктурой VMware vSphere. Туда входит VMware View Open Client, ESXCLI 5.1, vSphere Perl SDK, Ruby vSphere console, набор скриптов vGhetto, vmkfstools и многое другое. В приложении реализована полноценная многозадачность, решение является полностью Open Source продуктом и поставляется в виде образа для Raspberry Pi.
Тулбокс Xtravirt Advantage vPi можно использовать стильным администраторам, которые хотят всегда иметь с собой средство управления виртуальной инфраструктурой VMware vSphere.
Это гостевой пост компании ИТ-ГРАД - ведущего сервис-провайдера, предоставляющего услуги аренды виртуальных машин.
Для подавляющего большинства компаний наличие двух или более собственных площадок все еще остается непозволительной роскошью. И что же делать с обеспечением непрерывности оказания ИТ-сервисов в такой ситуации? Вывод очевиден: если по каким-то причинам нет возможности использовать публичное облако в качестве основной площадки - его можно использовать в качестве резервной!
С развитием облачных технологий все большее количество заказчиков готовы отказаться от собственной инфраструктуры в пользу высокодоступных сервисов по размещению виртуальных машин в публичном облаке.
Однако остаются ситуации, обусловленные спецификой деятельности компании, наличием уже осуществленных проектов по построению приватного облака, специфическими требованиями по производительности, безопасности и т.п., которые, возможно, временны, но не дают возможности воспользоваться публичным облаком для хостинга своих ИТ-сервисов.
Возможно ли разместить резервную площадку в публичном облаке?
С какими трудностями придется столкнуться при реализации проекта?
И, в конце концов, сколько это будет стоить?
Такие вопросы все чаще возникают как на просторах сети, так и у потенциальных потребителей наших облачных услуг.
У некоторых виртуальных машин на платформе VMware vSphere может оказаться такая ситуация, что на одном виртуальном диске VMDK окажутся 2 логических раздела - например, диски C и D в Windows. Произойти это может вследствие P2V-миграции физического сервера в ВМ или изначальной конфигурации машины.
При этом, для каких-то целей вам может потребоваться эти логические диски разнести по двум файлам VMDK (например, для целей хранения дисков на разных "ярусах" хранения). Решить эту проблему весьма просто с помощью VMware vCenter Converter (мы писали о нем тут).
Делается так это все так:
Начинаем процесс конвертации виртуальной машины
Идем в мастере конверсии в Options
Для раздела "Data to copy" выбираем "Edit"
Выбираем опцию "Data copy type" и меняем ее на "Select volumes to copy".
Далее на вкладке "Target Layout" в представлении "Advanced" настраиваем разнесение логических дисков по разным vmdk, как на картинке ниже.
Как многие из вас знают, мы своевременно обновляем посты про диаграммы портов и соединений различных компонентов VMware vSphere и других продуктов компании. Об этом можно почитать, например, тут, тут и тут.
Недавно вышло очередное обновление схемы портов VMware vSphere 5.1. Схема уже является официальной и приведена в KB 2054806.
Приятно также и то, что теперь в этом же документе в виде таблицы приведены все порты различных компонентов VMware vSphere 5.x и назначение соединений:
Некоторое время назад компания VMware инициировала Project Serengeti, целью которого было обеспечение возможности запуска кластеров Apache Hadoop на виртуальной платформе (в частности, VMware vSphere). Это одна из первых серьезных инициатив VMware в сегменте Big Data.
Совсем недавно была выпущена бета-версия расширений VMware vSphere Big Data Extensions v1.0 Beta, которые позволяют применить все наработки Serengeti для создания виртуальных машин с Hadoop на борту. Эти расширения обеспечивают жизненный цикл Hadoop на платформе VMware vSphere и позволяют отслеживать потребляемые ими ресурсы.
Возможности VMware vSphere Big Data Extensions v1.0 Beta:
Графический интерфейс Big Data Extensions. Он позволяет создавать, масштабировать и удалять кластеры Hadoop. Кроме того, доступен отдельный мониторинг и контроль ресурсов этих виртуальных машин.
В целом, VMware заявляет, что Apache Hadoop исполняется в виртуальных машинах практически без потерь производительности (об этом можно почитать здесь):
Скачать VMware vSphere Big Data Extensions v1.0 Beta можно по этой ссылке.
Таги: VMware, vSphere, Hadoop, Big Data, Performance
Мы часто пишем заметки о безопасности виртуальной инфраструктуры VMware vSphere и других продуктов на данной платформе (их можно найти по тэгу Security). И вот на днях я натолкнулся на интересную статью "It’s a Unix system, I know this!", в которой есть одна умная мысль, касающаяся настройки безопасности, и которую я часто пытаюсь донести до заказчиков. А именно: некорректное планирование и исполнение процедур по обеспечению безопасности может привести к еще большим проблемам как с точки зрения конфигурации виртуальной среды, так и с точки зрения самой безопасности.
Итак, обратимся к статье. Есть такая организация в штатах Defense Information Systems Agency (DISA), которая выпускает документ Security Technical Implementation Guide (STIG), являющийся руководящим документом по обеспечению безопасности для правительственных организаций. Есть подозрение, что в части виртуальных машин он сделан на основе VMware vSphere Security Hardening, однако не из самой актуальной версии последнего.
Так вот в этом DISA STIG есть пункты, касающиеся виртуальных машин, например, пункт про отключение операций Copy/Paste с гостевой ОС виртуальной машины из ОС компьютера, где выполняется vSphere Client.
Посмотрим, как рекомендуется выполнить эту процедуру:
To edit a powered-down virtual machine’s .vmx file, first remove it from vCenter Server’s inventory. Manual additions to the .vmx file from ESXi will be overwritten by any registered entries stored in the vCenter Server database. Make a backup copy of the .vmx file. If the edit breaks the virtual machine, it can be rolled back to the original version of the file.
1. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Storage. Right-click on the appropriate datastore and click Browse Datastore. Navigate to the folder named after the virtual machine, and locate the <virtual machine>.vmx file. Right-click the .vmx file and click Remove from inventory.
2. Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client.
3. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell, and Options, respectively. Start the ESXi Shell service, where/as required.
4. As root, log in to the ESXi host and locate the VM’s vmx file.
# find / | grep vmx
Add the following to the VM’s vmx file.
keyword = “keyval”
Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials.
If connecting to vCenter Server, click on the desired host.
Click the Configuration tab.
Click Storage.
Right-click on the appropriate datastore and click Browse Datastore.
Navigate to the folder named after the virtual machine, and locate the <virtual machine>.vmx file.
Right-click the .vmx file and click Add to inventory. The Add to Inventory wizard opens.
Continue to follow the wizard to add the virtual machine.
Круто, да? Это все для того, чтобы просто отключить копирование из консоли ВМ (для одной машины), которое если уж кому-то очень сильно понадобится - он сделает все равно через принтскрин или еще как.
А теперь подумаем, к чему это все может привести:
В процессе такой настройки администратор может что-то испортить.
Сотни виртуальных машин обработать таким способом очень долго и нудно.
Такая процедура открывает больше дырок, чем закрывает (администратор снимает Lockdown хоста, делает операции в шеле и тыркается по вицентру).
Контролировать исполнение процесса очень сложно - все ли локдауны были закрыты, по всем машинам ли мы прошлись и т.п.
Конечно же, есть простой и элегантный способ сделать все это сразу для всех ВМ и с помощью PowerCLI через методы, описанные в пунктах vm.disable-console-copy и vm.disable-console-paste документа vSphere Hardening Guide.
Однако те из вас, у кого в компании есть отдел информационной безопасности, знают что такое формализм этих ребят, которые может в виртуализации и не разбираются, зато прекрасно понимают, что приведенный выше гайд несколько отличается от двух строчек на PowerShell.
И, хотя это в основном касается западных организаций, в отечественных крупных компаниях тоже возникают проблемы из-за подобных процедур.
Так вот какова мораль сей басни:
При разработке руководящих документов по обеспечению безопасности виртуальной инфраструктуры поймите, какие требования являются обязательными, а какие можно реализовать факультативно (то есть не реализовывать вовсе). Минимизируйте число обязательных требований и по мере необходимости расширяйте.
Используйте последние версии руководящих документов по ИБ от вендоров и всегда обновляйте свои собственные (хотя бы с выходом мажорной версии продукта).
Максимально применяйте автоматизацию при выполнении процедур по конфигурации безопасности. В VMware vSphere и других продуктах VMware можно автоматизировать практически все.
Если выполнение требования к ИБ виртуальной среды потенциально может открыть еще больше дырок, вызвать ошибки конфигурации и причинить еще беды, подумайте - а может стоит отказаться от этого требования или переформулировать его?
Ну а если кратко - с головой надо подходить, а формализм отставить. Больше интересных подробностей - в статье.
Продолжаем знакомить вас с багами VMware vSphere 5.1 - ведущей платформы виртуализации. На этот раз мы расскажем о баге VMware vSphere Client, для чего откроем вкладку редактирования пользователя и посмотрим на его свойства:
Такую картину мы увидим в том числе и тогда, когда пользователь VMware ESXi был создан автоматически, например, при использовании функций AutoDeploy и Host Profiles. Не очень понятно, почему это пользователю при создании по дефолту гарантируются права на доступ к консоли ESXi, а вот в списке групп, где он состоит, наблюдается пустота.
Все на самом деле просто: в vSphere 5.1 поменялся подход к безопасности, а вот сделать обновление vSphere Client забыли, так как сейчас идет переход на vSphere Web Client, и никому нет дела до толстого клиента. Соответственно, аспекты этого бага таковы:
Галка "Grant shell access to this user" ни на что не влияет. Важно только, назначена ли роль Administrator пользователю (что позволит ему войти в консоль сервера).
Поле Group пустое, так как ESXi больше не использует информацию из /etc/groups, а использует свою модель пользователей и групп:
Поэтому вновь создаваемый пользователь с галкой "Grant shell access to this user" не сможет соединиться по SSH и зайти в консоль, то есть это баг UI:
Иногда возникает потребность правильно выключить виртуальные машины VMware vSphere в определенной последовательности, чтобы не нарушить консистентность данных и приложений. Требуется это при различных сценариях обслуживания инфраструктуры, переездах оборудования, подготовке к отключениям электричества и т.п. Ну а потом, соответственно, эти ВМ нужно включить - и тоже в нужной последовательности.
Специально для таких случаев Graham French допилил скрипт на PowerShell / PowerCLI, который автоматизирует процессы Startup / Shutdown для виртуальных машин на ESXi. Грэхам подошел к задаче научно - он разделил все ВМ на 5 слоев, отражающих очередность выключения машин:
Phase 1 - веб-серверы, балансировщики нагрузки, принт-серверы - то есть некритичные машины и машины на краю периметра датацентра.
Phase 2 - серверы приложений и другие серверы, являющиеся фронтэнд-звеном в архитектуре многокомпонентных приложений.
Phase 3 - серверы баз данных и кластеризованные серверы.
Phase 4 - NAS-серверы и файловые серверы.
Phase 5 - сервисы обеспечения инфраструктуры: Active Directory, DNS, DHCP, виртуальные модули (Virtual Appliances).
Соответственно, правильной схемой выключения виртуальных машин является последовательность Phase 1 -> Phase 5. Скрипт принимает на вход имена виртуальных машин в CSV-файлах, а также умеет выключать/включать и физические серверы:
Для включения машин используем обратную последовательность Phase 5 -> Phase 1:
Сам скрипт Startup / Shutdown и примеры CSV-файлов можно скачать по этой ссылке.
Недавно Duncan Epping опубликовал интересную статью о параметре Mem.MinFreePct, который есть в настройках сервера VMware ESXi из состава vSphere. По-сути, этот параметр определяет, какое количество оперативной памяти VMkernel должен держать свободным на хосте, чтобы всегда были доступные ресурсы под нужды системы, и хост не вывалился в PSOD.
В VMware vSphere 4.1 параметр Mem.MinFreePct составлял 6% и его можно было изменять с помощью следующей команды:
vsish -e set /sched/freeMemoryState/minFreePct <Percentage>
Например, вот так можно было установить Mem.MinFreePct в значение 2%:
vsish -e set /sched/freeMemoryState/minFreePct 2
Этак команда, кстати, не требует перезагрузки, но зато после перезагрузки значение Mem.MinFreePct не сохраняется. Поэтому данную команду, если требуется, нужно занести в /etc/rc.local (подробнее в KB 1033687).
Параметр этот очень важный, поскольку от него зависят пороги использования различных механизмов оптимизации памяти хоста ESXi. При этом, если памяти на хосте много (например, десятки гигабайт), то держать постоянно 6% свободной памяти может быть для кого-то расточительством. Поэтому, начиная с VMware vSphere 5.0, параметр Mem.MinFreePct является "плавающим" и устанавливается в зависимости от объема физической памяти на хосте ESXi.
Вот какие значения принимает Mem.MinFreePct в зависимости от того, сколько RAM есть на вашем физическом хост-сервере:
Процент необходимой свободной памяти
Объем памяти хоста ESXi
6%
0-4 ГБ
4%
4-12 ГБ
2%
12-28 ГБ
1%
Больше 28 ГБ
А вот какие механизмы оптимизации памяти на хосте работают, если свободной памяти становится все меньше и меньше:
Состояние свободной памяти хоста
Пороговое значение
Какие механизмы оптимизации памяти используются
High
6%
-
Soft
64% от значения MinFreePct
Balloon, Compress
Hard
32% от значения MinFreePct
Balloon, compress,swap
Low
16% от значения MinFreePct
Swap
Интересно, конечно, но как-то бесполезно. Зачем загонять хост в такие лимиты? Лучше как минимум процентов 10 всегда держать свободными и своевременно покупать новые серверы.
Компания VMware опубликовала очередной номер своего технического журнала VMware Technical Journal Summer 2013, в котором разбираются наиболее интересные технические аспекты решений для виртуализации на весьма глубоком уровне (зачастую даже с математическими выкладками). Напомним, что о предыдущем выпуске VMware Technical Journal мы писали вот тут. Как и в прошлом выпуске все статьи доступны онлайн и как PDF (5 МБ).
Мне понравились "Redefining ESXi IO Multipathing in the Flash Era" и "Methodology for Performance Analysis of VMware vSphere under Tier-1 Applications".
На днях компания VMware объявила о начале публичного бета-тестирования своего нового средства для анализа логов VMware vSphere - VMware vCenter Log Insight 1.0. Продукт поставляется в виде виртуального модуля (Virtual Appliance), который развертывается как обычный OVF-пакет, после чего становится доступен сбор и анализ данных syslog с серверов VMware ESXi 4.1, 5.0, 5.1, а также vCenter Server Appliance и других источников. Кроме того, Log Insight может быть интегрирован с vCenter Operations Manager.
Возможности VMware vCenter Log Insight 1.0:
High Performance Ingestion - Log Insight принимает данные от syslog или через API на скорости до 1000 Мбит/с на один виртуальный модуль
Near Real-Time Search - входящие данные доступны для поиска почти сразу и могут быть агрегированы с историческими данными в одном большом логе.
Aggregation - данные группируются методом похожим на GROUP-BY в реляционных БД.
Runtime Field Extraction - Log Insight может доставать данные из сырого лога средствами регулярных выражений.
Dashboards - администраторы могут создавать свои дэшборды из запросов к базе логов.
Scalability - инфраструктуру Log Insight можно наращивать за счет добавления дополнительных серверов.
Когда-то давно мы публиковали заметки о P2V-миграции физических серверов в виртуальные машины на платформе тогда еще VMware ESX Server (а также рассказывали о необходимых действиях после миграции). С тех пор многое изменилось, вышел VMware vCenter Converter Standalone 5.0, процесс миграции стал проще и стабильнее, а также накопилось пару моментов, о которых можно рассказать. Кроме того, появилась отличная статья на эту тему. Итак, есть 3 типа P2V-миграции...
Полгода назад мы уже писали о решении VMware vCloud Automation Center (vCAC), которое позволяет управлять облачной инфраструктурой предприятия (SaaS, PaaS, IaaS) средствами единого решения, построенного поверх VMware vCloud Director (для IaaS-инфраструктуры) и разработанного на базе решения DynamicOps (бывший продукт Virtual Resource Manager, VRM).
vCloud Automation Center упрощает доступ пользователям к облачным сервисам, предлагая портал самообслуживания, предназначенный для потребления различных aaS-услуг. Пользователь, заходя на портал, видит сервисы, к которым ему предоставлен доступ, выбирает нужный ему сервис и размещает запрос на его развертывание.
Улучшенная интеграция с vCloud Director. Владельцы ВМ могут развертывать объект vApp как единую сущность, но управлять каждой его ВМ по-отдельности.
Поддержка модели выделения ресурсов Pay-As-You-Go в vCloud Director. Администраторы могут создавать резервирование ресурсов по моделям Pay-As-You-Go, Reservation Pool или Allocation Pool.
Поддержка средства мониторинга и защиты корпоративной инфраструктуры vCloud Networking and Security (vCNS). vCAC теперь может обнаруживать такие сетевые ресурсы как сети VXLAN, балансировщики и security groups.Теперь их можно назначать виртуальным машинам при развертывании.
Поддержка гипервизора KVM (RHEV) и средства управления Red Hat Enterprise Virtualization Manager 3.1.
Improved Resource Reclamation
Улучшенный мехнизм настройки рабочих процессов (Improved Workflow Customization). Администратор может указать различные параметры аренды ВМ пользователем, включая возможность пролонгации аренды.
Метрики производительности для vSphere. Теперь эти метрики используются для определения неактивных ВМ, являющихся кандидатами на возврат в общий пул ресурсов (reclamation).
Поддержка виртуальных машин на платформе Amazon Web Service (EC2) для вывода ВМ из эксплуатации.
Site Recovery Manager Compatibility
Улучшенная интеграция со средством катастрофоустойчивости vCenter Site Recovery Manager. В версии 5.2 vCAC корректно обнаруживает отоношения между primary и recovery виртуальными машинами.
Internationalization
Поддержка интернационализции на уровне L0/L1. vCAC 5.2 поддерживает установку на локализованные версии ОС с non-ASCII символами (French, German, Japanese,
и Simplified Chinese). Пока без русского.
Installation
Поддержка модели лизензирования VMware V8 licensing. vCAC 5.2 поддерживает стандартные лицензионные ключи с VMware License Portal.
Compatibility Поддержка дополнительных гостевых ОС:
CentOS 5.9 (32- and 64-bit)
CentOS 6.3 (32- and 64-bit)
Windows 8
Windows Server 2012
Documentation
Информация о vCloud Automation Center Self-Service Portal теперь включена в документ
vCloud Automation Center Installation Guide.
Информация об интеграции vCAC с KVM (RHEV) теперь включена в vCloud Automation
Center KVM (RHEV) Integration Guide.
Информация о многомашинных сервисах и интеграции с vCloud Director включена в vCloud Automation Center What’s New Guide и vCloud Automation Center Multi-Machine Guide
Информация о vCAC Designer теперь есть в vCloud Automation Center Extensibility
Guide.
Все оставшиеся аспекты решения vCAC теперь есть в vCloud Automation Center Operating Guide.
Для проверки возможности обновления продукта на версию vCAC 5.2 может быть использован vCloud Automation Center Prerequisite Checker, идущий в комплекте поставки с продуктом:
Детальная информация о требованиях к обновлению на vCAC 5.2 приведена здесь.
Теперь, где можно более подробно ознакомиться с решением VMware vCloud Automation Center. Во-первых, есть вот такой ресурс - http://www.vcacteam.info/. Там собрано все, что может понадобиться администратору для понимания возможностей продукта.
Во-вторых, хорошая статья про интеграцию рабочих процессов VMware vCenter Orchestrator (vCO) и vCAC.
Некоторые из вас, возможно, в курсе, что существует такой проект Google Authenticator, который позволяет организовать двухфакторную аутентификацию через телефон (как по СМС, так и через приложение), которая позволяет не только вводить свой постоянный пароль, но и дополнительно временно генерируемый код, что существенно снижает риски несанкционированного доступа. Возможно, кто-то из вас использует это для своей почты на GMAIL:
Данный способ аутентификации очень надежен, так как злоумышленник без вашего телефона не получит доступа к сервису, поскольку он не получит временный пароль, а украв ваш телефон, он тоже не получит доступа, так как не знает постоянного пароля. Однако и этот способ не защищает от древнейшей утилиты взлома шифров и паролей - раскаленного утюга.
Компания VMware несколько доработала этот продукт, и на сайте проекта VMware Labs появился новый флинг - ESXi Google Authenticator, который позволяет организовать двухфакторную аутентификацию для доступа к консоли хост-серверов по SSH.
Для данного механизма обеспечения дополнительной безопасности поддерживаются хост-серверы ESXi 5.0 и 5.1, при этом допускается несколько администраторов одного сервера, использующих Google Authenticator (только ESXi 5.1).
Основные возможности ESXi Google Authenticator:
Поддержка двухфакторной аутентификации как для ESXi Shell, так и для доступа через SSH.
Поддержка нескольких логинов для ESXi 5.1 и одного (root) для ESXi 5.0.
Поддержка 30-секундных кодов TOTP (меняются каждые полминуты).
Поддержка кодов аварийного логина на случай, если телефон был украден (emergency scratch codes).
Защита от атак с повторением запросов.
Технически аутентификация в ESXi Google Authenticator организована средствами модуля PAM (Pluggable Authentication Module) и специального приложения, доступного для платформ Android, iOS и Blackberry.